I usually like to discover other cultural usages and try understand what I feel chocking from my cultural point. Not for THIS.
I strongly believe this kind of stupidity should be removed as soon as possible. It is an insult to humanity. And the better way to put bareers between people. White British, White Irish or Mixed Black African and White and Mixed Black Caribbean and White. What a bullshit !!!!
The other day, I wanted to prepare some videos of my favorite reggae and soul tunes for uploading them to YouTube.. My goal was very simple: prepare a video with a static image and the music I wanted to upload..
After briefly digging for a simple software to do that, which I could not found, I said "hey, why not doing it with liquidsoap !". Well, that is fairly easy ! Video support in liquidsoap is very young, but the amount of things that can be done is already quite important, so I though this would be an interesting example..
All you have to do is to prepare a PPN version of the picture, using convert /path/to/image.jpeg /path/to/image.ppn and have the mp3 or ogg file in an other place...
From the scripting point of view, the only difficult thing is to have liquidsoap stop at the end of the song.. As liquidsoap is mainly a streaming language, it is not designed to be able to stop easily. It should be made better soon, but for now I had to use a special trick: compose sequentially the song with a blank source. On the blank source, I add special metadata such that the output file is reopened with a new title when the song has ended. Eventually, the shutdown is triggered when adding the new metadata on the blank source.
Here is the code:
# Log to stdout
set("log.file",false)
set("log.stdout",true)
# Disable real-time processing, to process with the maximun speed
set("root.sync",false)
# Enable video
set("frame.video.channels",1)
# The video source using a static image
s = video.image(width=240,height=240,x=40,"/tmp/bla.ppm")
# The audio song.
audio = single("/tmp/bla.mp3")
# The special metadata function, that
# also triggers the shutdown..
def end_meta(_) =
shutdown ()
[("title","prout")]
end
# This is the blank source
bl = map_metadata(insert_missing=true,update=false,end_meta,blank())
# And the final source: the sequence song and blank added
# with the video of the static image..
final = add([sequence([audio,bl]),s])
# Output to a theora file, reopen on new metadata..
output.file.theora(reopen_on_metadata=true,"/tmp/$(title).ogv",
final) Some recent discussions made me remember about this very nice trailer...
The interesting moment is at 01:45...
Just a quick note that I was planning to write as soon as possible: I m (still) having fun with debian !.
Yes, things go slowly, yes we consume a lot of energy to discuss again and again the same things.. But, hey, that s what I am proud of !
Somehow, I truly appreciate people with which I had strong disagreement. I didn t like the moments when this generated frustration for me, but when I look at the overall picture, I really believe there are not a lot of projects who can still go on *and* support the level of free speech and opinions that we have. Diversity of opinions is a difficult thing for big projects, and I am proud we can afford it !
"We will not hide problems from our users." is one of the most meaningful sentence I got from this project, and all of this makes real sense to me.
It is democracy !
There seems to be indeed a meme on the
various
use
of SSH. So far I ve not seem mine, so here it is !
If you use the -w option when connecting using SSH, and if you have the correct configuration, then two virtual network interfaces will be created on both the client and the server.
Using these interfaces with a bit of routing and resolving magic, you can establish a full connection tunneled through an SSH connection !
> I believe the issue is the one described in [3], but I couldn't find theGrmblf...
> corresponding commit on the svn. Well, then my work on hiding security critical commits in the cloud of other commits seems to have worked quite well. I guess that the pointers above should give you enough details to either find the appropriate fixes\reproduce them, or write your own patch.
After my last post about the ongoing debate on the new process to accept and handle debian project members, Rapha l Hertzog proposed
an alternative organisation which could be a solution, but misses the most important fact: how the people in charge of the process would be chosed and dismissed. Rapha l Hertzog wants that we consider a group of skilled and trustfull people in charge of giving and revoking powers to lower class of developers, on a per-event basis. Their procedure would be an internal vote amongst this group, and they would be called the "Debian Community Managers". Although it could be a good idea, it really misses the MOST IMPORTANT FACT: how they are chosed and to whom are they responsible. As a reply to my comment, Rapha l propose that they would be elected at first, and then nominated/revoked on the basis of the decision procedure mentioned above. Not only is it exactly what have been in place for the last years in the various core teams, but also it is a dangerous naive vision of how powers and regulations must happen. Before the Debian project started to consider these issues, the various ideas to build a system where the majority is ruled by a minority and the means to prevent the most important issues has already been studied, in the field of Law and how to write a Constitution for a democratic system. The goal of a democratic system is to put some higher power in the hand of several, but prevent as much as possible any issue. And preventing means act before shit happens, not after. Furthermore, power has to be divided into several domains, where the people in charge of these domains are strongly seperated and share as less common interest as possible. Hence, the goal of a constitution is to weaken power and put barreers, even if this leads to slow and frustrating reform processes. In the same idea, elections, which redraw the positions, are planed on a regular basis, and if the previously elected people were good, they are relected, not the opposite, in which if they aren't good they are dismissed. Again, we prevent issues, so the requirement to be responsible for what you did is implicit. And, last, it is well known that the less direct a decision process is, the less democratic it is. Hence, one should always prefer direct elections to indirect nominations. Now, coming back to Debian, we can have a very similar distinction in the various powers available:
Following the recent announce about an intent to extend debian membership to various levels of contribution, I would like to add my two cents.. Some bloggers mentioned how they disagree on the notion of various level of rights, claiming that it was yet another class inequality. Some other bloggers mentioned their support to the proposal, and other felt that the announcement was badly done. I, for myself, don't have an objection to the idea that they should be various level of rights. I do like the notion of anarchism, but I have some doubts it can extend to a wide group of persons. Besides, I personally don't want to have rights on everything, since I don't want to be responsible for them. As for real life, I believe the less broken system to rule a big group of people is democracy. And, as such, I don't have objection to a system establishing different levels of rights, provided it is transparent and responsible to the majority of members. In particular, voting right and vote outcomes should rule everything. According to the debian constitution, it is already the rule that most major decisions in the project can only be taken by votes. That's a good thing for actions and resolutions concerning the project. Now, concerning members, the proposition would establish new rule to accept and give rights to new coming users. Fine. But, I wouldn't think it is fair until the same process apply also to core teams, and until the basis of the project are the voters, which would choose or dismiss members of those teams. Inequality class, just like democracy, can be seen as a necessary evil. But inequality is balanced, to me, when there is a democratic process of electing and dismissing people. Then, we can hope that there won't be any sort of aristocracy.
I would like to add some clarifications to the debate on linux sound APIs that happened last friday on planet. First, despite being portrayed as such, I am nothing like an OSS zealot. I was just recently surprised that OSS developpement still exists and that no one cares. Hence, my initial motivation for my post was to correct false informations, not to advocate for any solution. Now, since the debat has been opened to the issue of linux sound APIs, I feel like adding my two bits. In particular, unlike Josselin, I don't believe that the debate is irrelevant. I, too, would like that we consider two levels for sound APIs:
Dear Adrian, I can only but complain about the "Guide Through The Linux Sound API Jungle" that you mention in your last post. All that is said there about OSS is pure FUD and only reflects a deep ignorance of the current project. It is a pitty to spread misinformations that deprecate the work of others without even trying to understand it. Here is what is said about OSS in this document: The Open Sound System is a low-level PCM API supported by a variety of Unixes including Linux. It started out as the standard Linux audio system and is supported on current Linux kernels in the API version 3 as OSS3. OSS3 is considered obsolete and has been fully replaced by ALSA. A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions. The OSS API is very low-level, based around direct kernel interfacing using ioctl()s. It it is hence awkward to use and can practically not be virtualized for usage on non-kernel audio systems like sound servers (such as PulseAudio) or user-space sound drivers (such as Bluetooth or FireWire audio). OSS3's timing model cannot properly be mapped to software sound servers at all, and is also problematic on non-PCI hardware such as USB audio. Also, OSS does not do sample type conversion, remapping or resampling if necessary. This means that clients that properly want to support OSS need to include a complete set of converters/remappers/resamplers for the case when the hardware does not natively support the requested sampling parameters. With modern sound cards it is very common to support only S32LE samples at 48KHz and nothing else. If an OSS client assumes it can always play back S16LE samples at 44.1KHz it will thus fail. OSS3 is portable to other Unix-like systems, various differences however apply. OSS also doesn't support surround sound and other functionality of modern sounds systems properly. OSS should be considered obsolete and not be used in new applications. ALSA and PulseAudio have limited LD_PRELOAD-based compatibility with OSS.And here is what one of the devs from OSS answered to this [1]:
It's pretty inaccurate FUD (From the URL address - it's Pulseaudio's author, right? I'd have expected him to know better). He's basically judging OSS per the old OSS/Free drivers, which is like 5 years ago, and even that he does wrong. First, *all* current implementations/emulations of OSSv3 do sample conversion. It's not even a property defined by the API but by the underlying drivers. Second, even OSSv3 supported surround, USB cards, etc. Third, arguing that "it cannot be virtualized" is disproven by the amount of emulations and alternative implementations existing out there and working in practice. (The main difficulty is mmap() API, which is very rarely used anyway, and even that can be done with, say, oss2pulse). Fourth, complaining about OSS API being awkward, is... well, awkward when you compare it to ALSA API, if you could compare it, since most ALSA API isn't documented. It's kinda funny he advocates using ALSA API (not in the quoted part above, but last time I read his blog he suggested it). Actual ALSA devs advocate against it, but using a sound library with multiple backends [2].If you read some documentation, you can understand that OSS has been the target of some kernel developpers that didn't like it to be reused in a commercial product, back in the 90s. Hence, ALSA was launched, and OSS was progressively discarded, while constantly being the target of FUD like this. OSS has then lived for almost 10 years in the dark side of the force, but eventually did the way back in July 2007. Ironically, now most of the developpement in the linux kernel is driven by commercial interests. Most of the original complains about OSS are now fixed, including all the FUD written in this guide. In particular, software mixing is now supported. Being also part of a project that writes code to handle sound input and output, I can only but complain about the mess in the area of sound APIs in linux. However, OSS should really be reconsidered. In particular, its API is designed in order to abstract as much as possible access to the sound card, so that application writers have as less as possible to do with sound conversion and the like Those who have tried to use ALSA may for instance compare that to the "set rate near" call in its API: this call will set the rate to what the hardware support and let you handle the conversion... For each application... Also, OSS API is available across all unices, except OSX, and there is even a BeOS port going on. Finally, OSS API is POSIX oriented, reading and writing on the sound card, being a matter of calling few ioctls and then reading from the device file. In the future, OSS developpement will most probably be done as a community project, and I believe it is now time to stop spreading false ideas about the project, and give it as much attention as the other projects. For the debian users who want to try OSS4, a package is available in the packaging team's svn repository. It has been sitting in NEW for some time, I hope it gets accepted at some point.
Dear Sylvain, There are two point I didn't get in your post on distributing ocaml libraries, could you please elaborate about them ? Following the recent post about my issues with byte swapping on amd64, I have received several answers.. Since comments were broken, Rupert sent me a good explanation of the cryptic code from OSS4. Let me remember you what it was doing: static inline short
bswap_16 (short x)
short y = 0;
unsigned char *a = ((unsigned char *) &x) + 1;
unsigned char *b = (unsigned char *) &y
*b++ = *a--;
*b++ = *a--;
return y;
unsigned char = one byte, which seems reasonable. Then, a is initialised at the second character of the two-characters value x, and b on the first of the returned (swapped) value y. Now, the two cryptic lines can be decomposed as follows: *(b++) = *(a--), which literally means "put in b the value from a, and then increase b and decrease a. When executing the second line, a points to the first character from x, and b to the second from y. As Rupert noticed, the second call could simply have been *b = *a, but this wouldn't have been l33t enough :) Now, about the original code, namely (x 8) (x >> 8), MadCoder (salut !), as well as another anonymous comment both suggested that this would be a type error. Indeed, I had noticed the wrong right shift, but no matter how I tried, with or without mask, with unsigned short, short, or uint16_t, as suggested by MadCoder, I always get the same corrupted sound.. So, thanks for your comments, I'm now trying to dig the issue down in the code that makes use of this function. Most likely the issue comes from a wrong transtyping there.. I am also wondering what's the efficiency of the above OSS4's code with regard to (x 8) (x >> 8). Any idea ? PS: Yes, text on comments are mangled a lot. This is a basic safehtml protection, and I don't have the control over it, sorry..
Mediawiki 1.13.0 has just been released. The debian package has been updated. I don't know yet wether it would be a good idea or not to ask for an inclusion into lenny. The changelog is important, and it seems a good release. I am looking for testers in order to nail down all possible issues in the package, as well as arguments, in favour or not, about this possible inclusion..
Some really weird issue just poped to my eyes today, while coding some big->little endian code for liquidsoap. We have a 2 bytes swaping code that does the following: ((x) & 0x00ff) 8 ((x) & 0xff00) >> 8) However, this is not working at all on my amd64/x86_64 box (core2duo CPU). I get a horrible saturated sound.. So, I copy-pasted this from oss4: static inline short
bswap_16 (short x)
short y = 0;
unsigned char *a = ((unsigned char *) &x) + 1;
unsigned char *b = (unsigned char *) &y
*b++ = *a--;
*b++ = *a--;
return y;
bswap_16 function included in byteswap.h from libc6-dev doesn't work either, and yields the same saturated sound..
Some weeks ago, we (the icecast packaging team) were requested an icecast2 backport for debconf8. It is now stuck in backports.org's NEW queue, feel free to unblock it.
Liquidsoap 0.3.8 has just been released. Initially targeted as a bugfix release, fixing a nasty race condition in playlist sources, this release is finally more important. It can be seen as the first minor release after the major changes that occured in 0.3.7. Several issues where fixed, but also new functionalities have been added, mostly on users' request. We also had a nice beer two weeks ago. There, we have met some users as well as developers. This was a nice occasion to discuss (...)
Thanks to the great work from, Sebastien Noel, the OSS4 package has made a great improvement ! An initial package has been commited to the SVN repository. It is not yet complete, but should work, provided you remove yourself the alsa modules (alsa force-unload, as root). I won't argue here about the sorry state of sound under linux, but you can read the links I already provided in the ITP for more details on this topic. Next to come: latest polishing, and then upload: yipee (...)
I've just uploaded a new package for the SPIP content management webapp. SPIP is a very powerfull CMS made by a team of french coders. It is widely used in the french-speaking part of internet, used in thousands of sites, ranging from personal home page to professional publication websites. SPIP is somehow not well known in the eglish-speaking world, probably because most of the things happen in French... However, it's fully translated and documented in English, as well as many other (...)
The plot.. We eventually released liquidsoap 0.3.7 !! Next.